Microprocessor-based computer systems have become prolific at all levels of the public and private sector. Because of this success and popularity, computer programs likewise have inundated the market. Despite the countless advances in both computer hardware and software, many major microprocessor developers have greatly attempted to maintain backward compatibility between new hardware and older software, that is, permitting the newer microprocessors to achieve vastly improved performance with newer software, while still allowing those same microprocessors to operate with older software. In order to maintain compatibility in whole or in part, various complex considerations arise. The embodiments described below deal with certain of these complex considerations, including the combination of multi-tasking and interrupt handling in microprocessor-based computer systems.
Multi-tasking microprocessors are those allowing various programs, or even tasks as part of those programs, to run near-simultaneously, with each program being presented with an environment so that it appears to the task, and often to the computer user, as if the microprocessor is only running a single task. Note that it is stated above that these tasks run "near-simultaneously". In actuality, the microprocessor commonly gives temporary control to each separate task and stores the state of the non-operating tasks; however, the switching rate as well as the microprocessor operation speeds are so high that it typically appears to the computer user that the tasks are operating simultaneously.
Multi-tasking presents yet another level of complexity in the area of operating in different modes for different tasks, particularly in view of modes used for certain older software. For example, newer microprocessors often include at least two modes, a first mode or native mode allowing more advanced operations (e.g., to support multi-tasking) and a second mode to ensure that older software can run on newer microprocessors. For example, INTEL manufactured the original 8086 microprocessor many years ago, and that microprocessor used "real addressing" and, thus, 8086 programs were said to have run in real mode. Since that time, newer microprocessors have evolved into the 80286, the 80386, the 80486 and now a fifth generation, including the PENTIUM. The PENTIUM, as well as many of its predecessors, typically operates in a native mode referred to as the "protected mode", which allows complex data handling, privilege checking, and other features to better support multi-tasking. However, in order to also provide compatibility with programs written for the 8086 "real mode", these processors also include a "virtual mode", which is a hybrid of the protected and real modes. When operating in the virtual mode, the 8086 program perceives that it has sole control of the microprocessor and expects it to operate in a mode comparable to the 8086. Presently, the virtual mode is entered by enabling the VM (virtual mode) flag in the Eflag register of the microprocessor. In general, the virtual mode permits one or more computer programs written for 8086 microprocessors to operate in conjunction with a monitor program (e.g., WINDOWS) on a more advanced .times.86 microprocessor under a multi-tasking environment. For example, many 8086 programs currently exist which will operate on more modern day 80486 or PENTIUM processors, where that 8086 program runs under the virtual mode (and therefore hereafter is referred to as a "virtual 8086 program") while the monitor program itself actually runs under the more advanced protected mode. The monitor program, therefore, acts as a conduit between the virtual 8086 program and the actual microprocessor to perform various emulation as known in the art. As explained below, however, this perception to the virtual 8086 program may cause operational inefficiencies, particularly in the context of interrupts as described below.
There are various types of interrupts, but they all have in common that they create a change of flow in the normal flow of computer program execution. Thus, microprocessors include some level of interrupt handling capability. However, when combined with multi-tasking capabilities, the interrupt control and handling architecture is likely to become even more complicated because one task may use interrupts given certain expectations which, without some intervention, may adversely affect another task. To better understand these complexities, first consider a common example of interrupt enabling and disabling as used by the older 8086 programs where there was no expectation of another task being multi-tasked with the 8086 program. Specifically, many 8086 programs repeatedly issue the CLI and STI instructions to handle external interrupts. As known in the art, the CLI instruction is used in the 8086 to dear an interrupt flag ("IF") in the flags register of the 8086 microprocessor so that the microprocessor would not accept any other external interrupt until the 8086 program later issued an STI instruction to reset IF. For example, if the 8086 program desired to access an index/register pair (e.g., a personal computer CMOS RAM), it typically must first program a value into the index port and thereafter read data out of the data port, while not allowing an external interrupt to occur between those two events. Thus, to achieve this activity, the 8086 program may first issue the CLI instruction before programming the value to the index port so that the microprocessor is not interrupted before the value is thereafter read from the data port Thus, after reading the data port the 8086 program would issue the STI instruction, thereby allowing the microprocessor to then accept other hardware interrupt requests. While the above approach using the CLI and STI instructions to affect the interrupt flag was generally acceptable where the 8086 program was the sole program operating for the 8086 microprocessor, it becomes a problem when that same program operated as a virtual 8086 program on a multi-tasking 80.times.86 microprocessor.
Given the above, various approaches arose to lessen the potential effects of the typical use of the CLI and STI instructions by an 8086 program. For example, one prior multi-tasking approach had the monitor program trap all instances where the 8086 program issued either a CLI or STI instruction, and emulate the anticipated action back to the virtual 8086 program. This approach was found to be inefficient because often the emulation required a great deal of time. Another approach is shown in UK Patent Application 9217612.2, published Mar. 24, 1993, and hereby incorporated herein by reference. In this approach, INTEL further added to its more recent .times.86 microprocessors an extension to its virtual mode, where this extension is often referred to as virtual 8086 mode extensions. As its name suggests, the virtual 8086 mode extensions is a further refinement of the virtual mode and, therefore is enabled in addition to enabling VM as described above. More particularly, the virtual 8086 mode extensions are enabled in the PENTIUM by setting the VME bit in the CR4 control register. With the VME bit enabled, additional virtual interrupt flags in the Eflags register come into play. Particularly, these architected bits include a virtual interrupt flag bit ("VIF bit"). Using this bit, the newer microprocessor includes additional code and circuitry which must determine if the VME bit (and the VM bit) is enabled. If so, for an instance of a CLI or STI instruction from a virtual 8086 program, the microprocessor allows such instruction to affect only the VIF bit and, therefore, not to change the value of the IF bit. Further, the value of the VIF bit is combined with a virtual interrupt pending bit ("VIP bit"), and the result is used by the emulation from the monitor program to more efficiently permit interrupt handling while the VME bit is enabled. While this approach improved upon prior approaches, it included various drawbacks. For example, it required additional microinstruction complexity because it had to determine whether or not VME was enabled and to alter either the IF bit or the VIF bit accordingly. In addition, this approach required additional complexity outside of the microprocessor chip, namely, that which was added to any external monitor program. For example, the various WINDOWS operating systems were required to include additional functionality to perform the emulation stated above in order to accommodate the virtual 8086 program running with the VME bit enabled. The additional complexity may reduce performance, and also creates the possibility that the creator of a monitor program does not adequately account for the nuances of the combination of multi-tasking, interrupt handling, and operating under virtual 8086 mode extensions.
In view of the above, there arises a need to address the drawbacks of current systems and to provide a microprocessor with circuits, systems, and methods for interrupt handling during virtual task operation.